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(54) Presentation architecture for network supporting implantable cardiac therapy devices 



(57) A cardiac therapy network architecture which 
collects data output by an implantable cardiac therapy 
device (102), processes that data, and distributes it to 
various knowledge workers (130,132,134,136). The 
cardiac therapy network implements a presentation ar- 



chitecture (800) that formats and encodes the data us- 
ing different formats and protocols to facilitate distribu- 
tion to and presentation on various computing devices 
(140,144,148,152) that might be utilised by the knowl- 
edge workers. 
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Description 

[0001] The present invention generally relates to im- 
plantable cardiac therapy devices and ways to present 
information obtained from the implantable therapy de- 
vices. 

[0002] Implantable cardiac therapy devices (ICTDs) 
are implanted within the body of a patient to monitor, 
regulate, and/or correct heart function. ICTDs include 
implantable cardiac stimulation devices (e.g., implanta- 
ble cardiac pacemakers, implantable defibrillators) that 
apply stimulation therapy to the heart as well as implant- 
able cardiac monitors that monitor heart activity. 
[0003] ICTDs typically include a control unit posi- 
tioned within a casing that is implanted into the body and 
a set of leads that are positioned to impart stimulation 
and/or monitor cardiac activity. With improved proces- 
sor and memory technologies, the control units have be- 
come increasingly more sophisticated, allowing them to 
monitor many types of conditions and apply tailored 
stimulation therapies in response to those conditions. 
[0004] ICTDs are typically capable of being pro- 
grammed remotely by an external programming device, 
often called a "programmer". Today, individual ICTDs 
are equipped with telemetry circuits that communicate 
with the programmer. One type of programmer utilizes 
an electromagnetic wand that is placed near the im- 
planted cardiac device to communicate with the implant- 
ed device. When used in a sterile field, the wand may 
be enclosed in a sterile sheath. The wand contains a 
coil that forms a transformer coupling with the ICTD te- 
lemetry circuitry. The wand transmits low frequency sig- 
nals by varying coil impedance. 
[0005] Early telemetry systems were passive, mean- 
ing that the communication was unidirectional from the 
programmer to the implanted device. Passive telemetry 
allowed a treating physician to download instructions to 
the implanted device following implantation. Due to 
power and size constraints, early commercial versions 
of the implanted devices were incapable of transmitting 
information back to the programmer. 
[0006] As power capabilities improved, active telem- 
etry became feasible, allowing synchronous bi-direc- 
tional communication between the implanted device 
and the programmer. Active telemetry utilizes a half-du- 
plex communication mode in which the programmer 
sends instructions in a predefined frame format and, fol- 
lowing termination of this transmission, the implanted 
device returns data using the frame format. With active 
telemetry, the treating physician is able to not only pro- 
gram the implanted device, but also retrieve information 
from the implanted device to evaluate heart activity and 
device performance. The treating physician may period- 
ically want to review device performance or heart activity 
data for predefined periods of time to ensure that the 
device is providing therapy in desired manner. Conse- 
quently, current generation implantable cardiac therapy 
devices incorporate memories, and the processors pe- 



riodically sample and record various performance pa- 
rameter measurements in the memories. 
[0007] Data pertaining to a patient's cardiac condition 
is gathered and stored by the programmer during pro- 
5 gramming sessions of the ICTDs. Analysis of the cardi- 
ac condition is performed locally by the programming 
software. Programmers offer comprehensive diagnostic 
capabilities, high-speed processing, and easy opera- 
tion, thereby facilitating efficient programming and time- 
10 |y patient follow-up. 

[0008] In addition to local analysis, TransTelephonic 
Monitoring (TTM) systems are employed to gather cur- 
rent cardiac data from patients who are remote from the 
healthcare provider. TTM systems are placed in pa- 
's tients 1 homes. They typically include a base unit that 
gathers information from the ICTD much like the pro- 
grammer would. The base unit is connected to a tele- 
phone line so that data may be transmitted to the med- 
ical staff responsible for that patient. An example of an 
20 ICTD TTM system is a service from St. Jude Medical® 
and Raytel® Cardiac Services called "Housecall™." 
This service provides current programmed parameters 
and episode diagnostic information for a plurality of 
events including stored electrograms (EGMs). Real- 
ms time EGMs with annotated status information can also 
be transmitted. 

[0009] Using a telephone and a transmitter, the TTM 
system provides both the medical staff and the patient 
the convenience of instant analysis of therapy without 

30 having the patient leave the comfort of home. Typically, 
real-time measurements are transmitted in just minutes. 
Patients may be closely monitored, and the medical staff 
has more control of their patient's treatment, thus ad- 
ministering better patient management. 

35 [0010] One challenge that still persists, however, is 
how to efficiently and effectively present patient infor- 
mation and cardiac data to medical personnel and other 
knowledge workers who might have an interest in the 
device data. People utilize different types of computing 

^0 devices to receive and view data, such as computers, 
portable computers, personal digital assistants, facsim- 
ile machines, and so on. These computing devices have 
different user interface capabilities and features. Ac- 
cordingly, there is a need for a system that delivers the 

^5 data to a wide variety of computing devices. 

[001 1] A cardiac therapy network architecture collects 
data output by one or more implantable cardiac therapy 
devices, processes that data, and distributes it to vari- 
ous knowledge workers. The cardiac therapy network 

so implements a presentation architecture that formats and 
encodes the data using different formats and protocols 
to facilitate distribution to and presentation on various 
computing devices with different user interface capabil- 
ities. 

55 [0012] Fig. 1 is a diagrammatic illustration of a cardiac 
therapy network architecture with an implantable cardi- 
ac therapy device (ICTD) connected to a network of 
computing systems used by various knowledge work- 
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ers. 

[001 3] Fig. 2 is a functional diagram illustrating infor- 
mation flow from the ICTD to the computing systems as- 
sociated with the knowledge workers. 
[0014] Fig. 3 is a functional diagram illustrating how 5 
the various computing systems share pieces of informa- 
tion to improve care given to the patient. 
[0015] Fig. 4 is a functional diagram illustrating infor- 
mation flow from the computing systems back to the 
ICTD. 

[0016] Fig. 5 is a simplified illustration of an ICTD in 
electrical communication with a patient's heart for mon- 
itoring heart activity and/or delivering stimulation thera- 
py. 

[0017] Fig. 6 is a functional block diagram of an ex- 
emplary implantable cardiac therapy device. 
[0018] Fig. 7 is a functional block diagram of an ex- 
emplary computing device that may be used in the com- 
puting systems of the cardiac therapy network architec- 
ture. 

[0019] Fig. 8 illustrates a presentation architecture im- 
plemented by the network architecture to facilitate dis- 
tribution and presentation of information from the ICTD 
to the knowledge workers. 

[0020] Fig. 9 is a functional block diagram of an ex- 
emplary presentation system to format and encode con- 
tent for delivery to the knowledge workers. 
[0021] Fig. 1 0 is a flow diagram of a method for pre- 
senting content to the knowledge workers. 
[0022] In the description that follows, like numerals or 
reference designators are used to reference like parts 
or elements. 

[0023] The following description sets forth a cardiac 
therapy network architecture in which data collected 
from an implantable cardiac therapy device is proc- 
essed and distributed to various knowledge workers. It 
is anticipated that the knowledge workers will utilize dif- 
ferent computing devices for receiving and viewing the 
data. These computing devices vary widely in terms of 
their user interface (Ul) capabilities. Accordingly, the 
network architecture implements a presentation archi- 
tecture that formats and distributes content to various 
computing devices with different user interface capabil- 
ities. 

45 

Cardiac Therapy Network 

[0024] Fig. 1 shows an exemplary cardiac therapy 
network architecture 100 that includes an implantable 
cardiac therapy device (ICTD) 1 02 coupled to a network so 
of computing systems associated with various knowl- 
edge workers who have interest in cardiac therapy. The 
ICTD is illustrated as being implanted in a human patient 
104. The ICTD 102 is in electrical communication with 
a patient's heart 1 06 by way of multiple leads 1 08 suit- 55 
able for monitoring cardiac activity and/or delivering 
multi-chamber stimulation and shock therapy. 
[0025] The ICTD 1 02 may communicate with a stan- 



dalone or offline programmer 1 1 0 via short-range telem- 
etry technology. The offline programmer 1 1 0 is equipped 
with a wand that, when positioned proximal to the ICTD 
102, communicates with the ICTD 102 through a mag- 
netic coupling. 

[0026] The ICTD 1 02 can alternatively, or additionally, 
communicate with a local transceiver 112. The local 
transceiver 112 may be a device that resides on or near 
the patient, such as an electronic communications de- 
vice that is worn by the patient or is situated on a struc- 
ture within the room or residence of the patient. The local 
transceiver 112 communicates with the ICTD 102 using 
short-range telemetry or longer-range high-frequency- 
based telemetry, such as RF (radio frequency) transmis- 
sions. Alternatively, the local transceiver 112 may be in- 
corporated into the ICTD 1 02, as represented by dashed 
line 111 . In this case, the ICTD includes a separate and 
isolated package area that accommodates high-fre- 
quency transmissions without disrupting operation of 
the monitoring and stimulation circuitry. 
[0027] Depending upon the implementation and 
transmission range, the local transceiver 112 can be in 
communication with various other devices of the net- 
work architecture 100. One possible implementation is 
for the local transceiver 112 to transmit information re- 
ceived from the ICTD 102 to a networked programmer 
1 1 4, which is connected to network 1 20. The networked 
programmer 114 is similar in operation to standalone 
programmer 1 1 0, but differs in that it is connected to the 
network 120. The networked programmer 114 may be 
local to, or remote from, the local transceiver 1 12; or al- 
ternatively, the local transceiver 112 may be incorporat- 
ed into the networked programmer 114, as represented 
by dashed line 116. 

[0028] Another possible implementation is for the lo- 
cal transceiver to be connected directly to the network 
120 for communication with remote computing devices 
and/or programmers. Still another possibility is for the 
local transceiver 112 to communicate with the network 
120 via wireless communication, such as via a satellite 
system 122. 

[0029] The network 1 20 may be implemented by one 
or more different types of networks (e.g., Internet, local 
area network, wide area network, telephone, cable, sat- 
ellite, etc.), including wire-based technologies (e.g., tel- 
ephone line, cable, fiber optics, etc.) and/or wireless 
technologies (e.g., RF, cellular, microwave, IR, wireless 
personal area network, etc.). The network 120 can be 
configured to support any number of different protocols, 
including HTTP ( Hyp erText Transport Protocol), TCP/IP 
(T ransmission Control Protocol/Internet Protocol), WAP 
(Wireless Application Protocol), Bluetooth, and so on. 
[0030] A number of knowledge workers are interested 
in data gathered from the implantable cardiac therapy 
device 102. Representative knowledge workers include 
healthcare providers 1 30, the device manufacturer 1 32, 
clinical groups 134, and regulatory agencies 136. The 
knowledge workers are interested in different portions 
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of the data. For instance, the healthcare providers 130 
are interested in information pertaining to a particular 
patient's condition. The manufacturer 132 cares about 
how the device is operating. The clinical groups 134 
want certain data for inclusion in patient populations that 
can be studied and analyzed. The regulatory agencies 
136 are concerned whether the devices, and various 
treatments administered by them, are safe or pose a 
health risk. 

[0031] The network architecture 1 00 facilitates distri- 
bution of the device data to the various knowledge work- 
ers. Information gathered from the device is integrated, 
processed, and distributed to the knowledge workers. 
Computer systems maintain and store the device data, 
and prepare the data for efficient presentation to the 
knowledge workers. The computer systems are repre- 
sented pictorially in Fig. 1 as databases. However, such 
system can be implemented using a wide variety of com- 
puting devices, ranging from small handheld computers 
or portable digital assistants (PDAs) carried by physi- 
cians to workstations or mainframe computers with 
large storage capabilities. The healthcare providers 1 30 
are equipped with computer systems 1 40 that store and 
process patient records 1 42. The manufacturer 1 32 has 
a computer system 1 44 that tracks device data 1 46 re- 
turned from ICTDs 102. The clinical groups 134 have 
computer systems 148 that store and analyze data 
across patient populations, as represented by a histo- 
gram 150. The regulatory agencies 136 maintain com- 
puter systems 1 52 that register and track healthcare risk 
data 154 for ICTDs. 

[0032] The network architecture 100 supports two- 
way communication. Not only is data collected from the 
ICTD 102 and distributed to the various computer sys- 
tems of the knowledge workers, but also information can 
be returned from these computer systems to the net- 
worked programmer 114 and/or the local transceiver 
112 for communication back to the ICTD 102. Informa- 
tion returned to the ICTD 1 02 may be used to adjust op- 
eration of the device, or modify therapies being applied 
by the device. Such information may be imparted to the 
ICTD 102 automatically, without the patient's knowl- 
edge. 

[0033] Additionally, information may be sent to a pa- 
tient notification device 1 60 to notify the patient of some 
event or item. The patient notification device 1 60 can be 
implemented in a number of ways including, for exam- 
ple, as a telephone, a cellular phone, a pager, a PDA 
(personal digital assistant), a dedicated patient commu- 
nication device, a computer, an alarm, and so on. Noti- 
fications may be as simple as an instruction to sound an 
alarm to inform the patient to call into the healthcare pro- 
viders, or as complex as HTML-based pages with 
graphics and textual data to educate the patient. Notifi- 
cation messages sent to the patient notification device 
160 can contain essentially any type of information re- 
lated to cardiac medicinal purposes or device operation. 
Such information might include new studies released by 



clinical groups pertaining to device operation and pa- 
tient activity (e.g., habits, diets, exercise, etc.), recall no- 
tices or operational data from the manufacturer, patient- 
specific instructions sent by the healthcare providers, or 

s warnings published by regulatory groups. 

[0034] Notifications can be sent directly from the 
knowledge worker to the patient. Additionally, the net- 
work architecture 100 may include a notification system 
170 that operates computer systems 172 designed to 

10 create and deliver notification messages 1 74 on behalf 
of the knowledge workers. The notification system 170 
delivers the messages in formats supported by the var- 
ious types of patient notification devices 160. For in- 
stance, if the patient carries a pager, a notification mes- 

15 sage might consist of a simple text statement in a pager 
protocol. For a more sophisticated wireless-enabled 
PDA or Internet-oriented cellular phone, messages 
might contain more than text data and be formatted us- 
ing WAP formats. 

20 [0035] Fig. 2 shows the flow of data from the implant- 
able cardiac therapy device 1 02 to the various computer 
systems used by the knowledge workers. Data from the 
ICTD is output as digital data, as represented by the 
string of 0's and 1 's. The data may consist of any number 

25 of items, including heart activity (e.g., IEGM), patient in- 
formation, device operation, analysis results from on- 
device diagnostics, and so on. 
[0036] A data integrator 200 accumulates the data 
and stores it in a repository 202. A processing system 

30 204 processes portions of the data according to various 
applications 206 that are specifically tailored to place 
the data into condition for various knowledge workers. 
For example, healthcare workers might be interested in 
certain portions of the data, such as the IEGM data and 

35 the patient information. Clinical scientists might be in- 
terested in the heart data, but do not wish to see any 
patient information. Manufacturers may be interested in 
the raw data stream itself as a tool to discern how the 
device is operating. Depending on the needs of the end 

40 worker, the processing system 204 takes the raw device 
data, evaluates its accuracy and completeness, and 
generates different packages of data for delivery to the 
various knowledge workers. The processed data pack- 
ages are also stored in the repository 202. 
[0037] When the data is ready for delivery, a distribu- 
tion/presentation system 208 distributes the different 
packages to the appropriate computer systems 140, 
144, 148, 152, and 172. The distribution/presentation 
system 208 is configured to serve the packages accord- 

50 jng to the protocols and formats desired by the computer 
systems. In this manner, the network architecture 100 
allows relevant portions of device data, collected from 
the ICTD, to be disseminated to the appropriate knowl- 
edge workers in a form they prefer. 

55 [0038] Once the ICTD data is delivered, the computer 
systems 1 40, 1 44, 1 48, 1 52, and 1 72 store the data and/ 
or present the data to the knowledge worker. The com- 
puter systems may perform further processing specific 
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to their use of the data. Through these processes, the 
knowledge workers create additional information that is 
useful to the patient, or other knowledge workers with 
interests in ICTDs. For example, from the ICTD data, 
the knowledge workers might devise improved thera- 5 
pies for a given patient, or create instructions to modify 
operation of a specific ICTD, or gain a better under- 
standing of how implantable cardiac devices operate in 
general, or develop better technologies for future gen- 
erations of ICTDs. Much of this created knowledge can 
be shared among the various knowledge workers. 
[0039] Fig. 3 shows how the various computing sys- 
tems 140, 144, 148, 152, and 172 can cooperate and 
share pieces of information to improve the care given to 
a patient. Where appropriate and legally acceptable, the 
computer systems may be configured to pass non-pri- 
vate information among the various knowledge workers 
to better improve their understanding of the implantable 
medical field. Clinical results 150 produced by the clin- 
ical computer systems 148 may be shared with health- 
care providers to improve patient care or with manufac- 
turers to help in their design of next generation devices. 
The sharing of information may further lead to better and 
timelier healthcare for the patients. 
[0040] If the collective knowledge base produces in- 
formation that may prove helpful to the patient, that in- 
formation can be passed to the notification system 1 72 
for delivery to one or more patients. Also, any one of the 
knowledge workers may wish to employ the notification 
system 172 to send messages to the patient(s). 
[0041] Fig. 4 shows, in more detail, the flow of infor- 
mation back from the various computer systems used 
by the knowledge workers to the implantable cardiac 
therapy device 1 02 orthe patient notification device 1 60. 
Information from any one of the computing system- 
s — healthcare computer system(s) 140, manufacturer 
computer system(s) 144, clinical computer system(s) 
148, regulatory computer system(s) 152 — orthe notifi- 
cation system 1 72 can be sent to a patient feedback sys- 
tem 400. The patient feedback system 400 facilitates 
delivery of the information back to the patient. It may be 
an independent system, or incorporated into one or 
more of the computing. It may alternatively be integrated 
into the notification system 172. 
[0042] The patient feedback system 400 may be im- 
plemented in many ways. As one exemplary implemen- 
tation, the patient feedback system 400 is implemented 
as a server that serves content back to the networked 
programmer 114, which then uses the information to 
program the ICTD 1 02 through a built in transceiver 116, 
local transceiver 112, or wand-based telemetry. As an- 
other possible implementation, the patient feedback 
system may be a cellular or RF transmission system that 
sends information back to the patient feedback device 
160. 

[0043] The network architecture 100 facilitates con- 
tinuous care around the clock, regardless of where the 
patient is located. For instance, suppose the patient is 



driving in the car when a cardiac episode occurs. The 
ICTD 102 detects the condition and transmits an alert 
message about the condition to the local transceiver 
112. The message is processed and delivered to a phy- 
sician's computer or PDA via the network 1 20. The phy- 
sician can make a diagnosis and send some instructions 
back to the patient's ICTD. The physician might also 
have a notification message that guides the patient to a 
nearest healthcare facility for further treatment sent via 
the notification system 1 70 to the patienfs notification 
device 160. Concurrently, the physician can share the 
patient's records online with an attending physician at 
the healthcare facility so that the attending physician 
can review the records prior to the patient's arrival. 

Exemplary ICTD 

[0044] Fig. 5 shows an exemplary ICTD 102 in elec- 
trical communication with a patient's heart 1 06 for mon- 
itoring heart activity and/or delivering stimulation thera- 
py, such as pacing or defibrillation therapies. The ICTD 
102 is in electrical communication with a patient's heart 
106 by way of three leads 10iB(1)-(3). To sense atrial 
cardiac signals and to provide right atrial chamber stim- 
ulation therapy, the ICTD 102 is coupled to an implant- 
able right atrial lead 1 08(1) having at least an atrial tip 
electrode 502, which typically is implanted in the pa- 
tient's right atrial appendage. To sense left atrial and 
ventricular cardiac signals and to provide left chamber 
pacing therapy, the ICTD 102 is coupled to a coronary 
sinus lead 108(2) designed for placement in the coro- 
nary sinus region via the coronary sinus. The coronary 
sinus lead 108(2) positions a distal electrode adjacent 
to the left ventricle and/or additional electrode(s) adja- 
cent to the left atrium. An exemplary coronary sinus lead 
108(2) is designed to receive atrial and ventricular car- 
diac signals and to deliver left ventricular pacing therapy 
using at least a left ventricular tip electrode 504, left atri- 
al pacing therapy using at least a left atrial ring electrode 
506, and shocking therapy using at least a left atrial coil 
electrode 508. 

[0045] The ICTD 1 02 is also shown in electrical com- 
munication with the patient's heart 1 06 by way of an im- 
plantable right ventricular lead 108(3) having, in this im- 
plementation, a right ventricular tip electrode 510, a right 
ventricular ring electrode 512, a right ventricular (RV) 
coil electrode 514, and an SVC coil electrode 516. Typ- 
ically, the right ventricular lead 108(3) is transvenously 
inserted into the heart 1 02 to place the right ventricular 
tip electrode 510 in the right ventricular apex so that the 
RV coil electrode 514 will be positioned in the right ven- 
tricle and the SVC coil electrode 51 6 will be positioned 
in the superior vena cava. Accordingly, the right ven- 
tricular lead 108(3) is capable of receiving cardiac sig- 
nals, and delivering stimulation in the form of pacing and 
shock therapy to the right ventricle. 
[0046] Fig. 6 shows an exemplary, simplified block di- 
agram depicting various components of the ICTD 102. 
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The ICTD 1 02 can be configured to perform one or more 
of a variety of functions including, for example, monitor- 
ing heart activity, monitoring patient activity, and treating 
fast and slow arrhythmias with stimulation therapy that 
includes cardioversion, defibrillation, and pacing stimu- s 
lation. While a particular multi-chamber device is shown, 
it is to be appreciated and understood that this is done 
for illustration purposes. 

[0047] The circuitry is housed in housing 600, which 
is often referred to as the "can", "case", "encasing", or 10 
"case electrode", and may be programmably selected 
to act as the return electrode for unipolar modes. Hous- 
ing 600 may further be used as a return electrode alone 
or in combination with one or more of the coil electrodes 
for shocking purposes. Housing 600 further includes a 15 
connector (not shown) having a plurality of terminals 
602, 604, 606, 608, 612, 614, 616, and 618 (shown 
schematically and, for convenience, the names of the 
electrodes to which they are connected are shown next 
to the terminals). 20 
[0048] To achieve right atrial sensing and pacing, the 
connector includes at least a right atrial tip terminal (A R 
TIP) 602 adapted for connection to the atrial tip elec- 
trode 502. To achieve left chamber sensing, pacing, and 
shocking, the connector includes at least a left ventricu- 25 
lar tip terminal (V L Tl P) 604, a left atrial ring terminal (A L 
RING) 606, and a left atrial shocking terminal (A L COIL) 
608, which are adapted for connection to the left ven- 
tricular ring electrode 504, the left atrial ring electrode 
506, and the left atrial coil electrode 508, respectively. 30 
To support right chamber sensing, pacing, and shock- 
ing, the connector includes a right ventriculartip terminal 
(V R TIP) 61 2, a right ventricular ring terminal (V R RING) 
614, a right ventricular shocking terminal (RV COIL) 
616, and an SVC shocking terminal (SVC COIL) 618, 35 
which are adapted for connection to the right ventricular 
tip electrode 510, right ventricular ring electrode 512, 
the RV coil electrode 514, and the SVC coil electrode 
516, respectively. 

[0049] At the core of the ICTD 1 02 is a programmable *o 
microcontroller 620 that controls various operations of 
the ICTD, including cardiac monitoring and stimulation 
therapy. Microcontroller 620 includes a microprocessor 
(or equivalent control circuitry), RAM and/or ROM mem- 
ory, logic and timing circuitry, state machine circuitry, 45 
and I/O circuitry. Microcontroller 620 includes the ability 
to process or monitor input signals (data) as controlled 
by a program code stored in a designated block of mem- 
ory. Any suitable microcontroller 620 may be used. The 
use of microprocessor-based control circuits for per- so 
forming timing and data analysis functions are well 
known in the art. 

[0050] For discussion purposes, microcontroller 620 
is illustrated as including timing control circuitry 632 to 
control the timing of the stimulation pulses (e.g., pacing 55 
rate, atrioventricular (AV) delay, atrial interconduction 
(A-A) delay, or ventricular interconduction (V-V) delay, 
etc.) as well as to keep track of the timing of refractory 



periods, blanking intervals, noise detection windows, 
evoked response windows, alert intervals, markerchan- 
nel timing, and so on. Microcontroller 220 may further 
include various types of cardiac condition detectors 634 
(e.g., an arrhythmia detector, a morphology detector, 
etc.) and various types of compensators 636 (e.g., or- 
thostatic compensator, syncope response module, 
etc.). These components can be utilized by the device 
102 for determining desirable times to administer vari- 
ous therapies. The components 632-636 may be imple- 
mented in hardware as part of the microcontroller 620, 
or as software/firmware Instructions programmed into 
the device and executed on the microcontroller 620 dur- 
ing certain modes of operation. 
[0051] The ICTD 102 further includes an atrial pulse 
generator 622 and a ventricular pulse generator 624 that 
generate pacing stimulation pulses for delivery by the 
right atrial lead 108(1), the coronary sinus lead 108(2), 
and/or the right ventricular lead 108(3) via an electrode 
configuration switch 626. It is understood that in order 
to provide stimulation therapy in each of the four cham- 
bers of the heart, the atrial and ventricular pulse gener- 
ators, 622 and 624, may include dedicated, independent 
pulse generators, multiplexed pulse generators, or 
shared pulse generators. The pulse generators 622 and 
624 are controlled by the microcontroller 620 via appro- 
priate control signals 628 and 630, respectively, to trig- 
ger or inhibit the stimulation pulses. 
[0052] The electronic configuration switch 626 in- 
cludes a plurality of switches for connecting the desired 
electrodes to the appropriate I/O circuits, thereby pro- 
viding complete electrode programmability. Accordingly, 
switch 626, in response to a control signal 642 from the 
microcontroller 620, determines the polarity of the stim- 
ulation pulses (e.g., unipolar, bipolar, combipolar, etc.) 
by selectively closing the appropriate combination of 
switches (not shown). 

[0053] Atrial sensing circuits 644 and ventricular 
sensing circuits 646 may also be selectively coupled to 
the right atrial lead 108(1), coronary sinus lead 108(2), 
and the right ventricular lead 1 08(3), through the switch 
626 to detect the presence of cardiac activity in each of 
the four chambers of the heart. Accordingly, the atrial 
(AIR. SENSE) and ventricular (VTR. SENSE) sensing 
circuits, 644 and 646, may include dedicated sense am- 
plifiers, multiplexed amplifiers, or shared amplifiers. 
Each sensing circuit 644 and 646 may further employ 
one or more low power, precision amplifiers with pro- 
grammable gain and/or automatic gain control, band- 
pass filtering, and a threshold detection circuit to selec- 
tively sense the cardiac signal of interest. The automatic 
gain control enables the ICTD 102 to deal effectively 
with the difficult problem of sensing the low amplitude 
signal characteristics of atrial or ventricular fibrillation. 
Switch 626 determines the "sensing polarity" of the car- 
diac signal by selectively closing the appropriate switch- 
es. In this way, the clinician may program the sensing 
polarity independent of the stimulation polarity. 
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[0054] The outputs of the atrial and ventricular sens- 
ing circuits 644 and 646 are connected to the microcon- 
troller 620 which, in turn, is able to trigger or inhibit the 
atrial and ventricular pulse generators 622 and 624, re- 
spectively, in a demand fashion in response to the ab- 5 
sence or presence of cardiac activity in the appropriate 
chambers of the heart. The sensing circuits 644 and 646 
receive control signals over signal lines 648 and 650 
from the microcontroller 620 for purposes of controlling 
the gain, threshold, polarization charge removal circuitry 
(not shown), and the timing of any blocking circuitry (not 
shown) coupled to the inputs of the sensing circuits 644 
and 646. 

[0055] Cardiac signals are also applied to inputs of an 
analog-to-digital (A/D) data acquisition system 652. The 
data acquisition system 652 is configured to acquire in- 
tracardiac electrogram signals, convert the raw analog 
data into a digital signal, and store the digital signals for 
later processing and/or telemetric transmission to an ex- 
ternal device 654. The data acquisition system 652 is 
coupled to the right atrial lead 1 08(1 ), the coronary sinus 
lead 108(2), and the right ventricular lead 108(3) 
through the switch 626 to sample cardiac signals across 
any pair of desired electrodes. 
[0056] The data acquisition system 652 may be cou- 
pled to the microcontroller 620, or other detection cir- 
cuitry, to detect an evoked response from the heart 1 06 
in response to an applied stimulus, thereby aiding in the 
detection of "capture". Capture occurs when an electri- 
cal stimulus applied to the heart is of sufficient energy 
to depolarize the cardiac tissue, thereby causing the 
heart muscle to contract. The microcontroller 620 de- 
tects a depolarization signal during a window following 
a stimulation pulse, the presence of which indicates that 
capture has occurred. The microcontroller 620 enables 
capture detection by triggering the ventricular pulse 
generator 624 to generate a stimulation pulse, starting 
a capture detection window using the timing control cir- 
cuitry 632 within the microcontroller 620, and enabling 
the data acquisition system 652 via control signal 656 
to sample the cardiac signal that falls in the capture de- 
tection window and, based on the amplitude, deter- 
mines if capture has occurred. 
[0057] The microcontroller 620 is f u rther coupled to a 
memory 660 by a suitable data/address bus 662, where- 
in the programmable operating parameters used by the 
microcontroller 620 are stored and modified, as re- 
quired, in order to customize the operation of the im- 
plantable device 102 to suit the needs of a particular 
patient. Such operating parameters define, for example, 
pacing pulse amplitude, pulse duration, electrode polar- 
ity, rate, sensitivity, automatic features, arrhythmia de- 
tection criteria, and the amplitude, waveshape and vec- 
tor of each shocking pulse to be delivered to the patient's 
heart 106 within each respective tier of therapy. With 
memory 660, the ICTD 102 is able to sense and store 
a relatively large amount of data (e.g., from the data ac- 
quisition system 652), which may transmitted to the ex- 



ternal network of knowledge workers for subsequent 
analysis. 

[0058] Operating parameters of the ICTD 102 may be 
non-invasively programmed into the memory 660 
through a telemetry circuit 664 in telemetric communi- 
cation with an external device, such as a programmer 
110 or local transceiver 112. The telemetry circuit 664 
advantageously allows intracardiac electrograms and 
status information relating to the operation of the device 
1 02 (as contained in the microcontroller 620 or memory 
660) to be sent to the external devices. 
[0059] The ICTD 1 02 can further include one or more 
physiologic sensors 670, commonly referred to as "rate- 
responsive" sensors because they are typically used to 
adjust pacing stimulation rate according to the exercise 
state of the patient. However, the physiological sensor 
670 may further be used to detect changes in cardiac 
output, changes in the physiological condition of the 
heart, or diurnal changes in activity (e.g., detecting 
sleep and wake states, detecting position or postural 
changes, etc.). Accordingly, the microcontroller 620 re- 
sponds by adjusting the various pacing parameters 
(such as rate, AV Delay, V-V Delay, etc.) at which the 
atrial and ventricular pulse generators, 622 and 624, 
generate stimulation pulses. While shown as being in- 
cluded within the device 102, it is to be understood that 
the physiologic sensor 670 may also be external to the 
device 1 02, yet still be implanted within or carried by the 
patient. Examples of physiologic sensors that may be 
implemented in device 1 02 include known sensors that, 
for example, sense respiration rate and/or minute ven- 
tilation, pH of blood, ventricular gradient, and so forth. 
[0060] The ICTD 102 additionally includes a battery 
676 that provides operating power to all of circuits 
shown in Fig. 2. If the device 1 02 is configured to deliver 
pacing or shocking therapy, the battery 676 is capable 
of operating at low current drains for long periods of time 
(e.g., preferably less than 1 0 u.A), and is capable of pro- 
viding high-current pulses (for capacitor charging) when 
the patient requires a shock pulse (e.g., preferably, in 
excess of 2 A, at voltages above 2 V, for periods of 10 
seconds or more). The battery 676 also desirably has a 
predictable discharge characteristic so that elective re- 
placement time can be detected. As one example, the 
device 102 employs lithium/silver vanadium oxide bat- 
teries. 

[0061] The ICTD 102 can further include magnet de- 
tection circuitry (not shown), coupled to the microcon- 
troller 620, to detect when a magnet is placed over the 
device 1 02. A magnet may be used by a clinician to per- 
form various test functions of the device 102 and/or to 
signal the microcontroller 620 that the external program- 
mer is in place to receive or transmit data to the micro- 
controller 620 through the telemetry circuits 664. 
[0062] The ICTD 102 further includes an impedance 
measuring circuit 678 that is enabled by the microcon- 
troller 620 via a control signal 680. Uses for an imped- 
ance measuring circuit 678 include, but are not limited 
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to, lead impedance surveillance during the acute and 
chronic phases for proper lead positioning or dislodge- 
ment; detecting operable electrodes and automatically 
switching to an operable pair if dislodgement occurs; 
measuring respiration or minute ventilation; measuring 
thoracic impedance for determining shock thresholds; 
detecting when the device has been implanted; meas- 
uring stroke volume; and detecting the opening of heart 
valves, etc. The impedance measuring circuit 678 is ad- 
vantageously coupled to the switch 626 so that any de- 
sired electrode may be used. 

[0063] In the case where the device 102 is intended 
to operate as an implantable cardioverter/defibrillator 
(ICD) device, it detects the occurrence of an arrhythmia, 
and automatically applies an appropriate electrical 
shock therapy to the heart aimed at terminating the de- 
tected arrhythmia. To this end, the microcontroller 620 
further controls a shocking circuit 682 byway of a control 
signal 684. The shocking circuit 682 generates shocking 
pulses of low (up to 0.5 Joules), moderate (0.5 - 10 
Joules), or high energy (11 to 40 Joules), as controlled 
by the microcontroller 620. Such shocking pulses are 
applied to the patient's heart 106 through at least two 
shocking electrodes, and as shown in this implementa- 
tion, selected from the left atrial coil electrode 508, the 
RV coil electrode 514, and/or the SVC coil electrode 
516. As noted above, the housing 600 may act as an 
active electrode in combination with the RV coil elec- 
trode 514, or as part of a split electrical vector using the 
SVC coil electrode 516 or the left atrial coil electrode 
508 (i.e., using the RV electrode as a common elec- 
trode). 

[0064] Cardioversion shocks are generally consid- 
ered to be of low to moderate energy level (so as to min- 
imize pain felt by the patient), and/or synchronized with 
an R-wave and/or pertaining to the treatment of tachy- 
cardia. Defibrillation shocks are generally of moderate 
to high energy level (i.e., corresponding to thresholds in 
the range of 5-40 Joules), delivered asynchronously 
(since R-waves may be too disorganized), and pertain- 
ing exclusively to the treatment of fibrillation. According- 
ly, the microcontroller 620 is capable of controlling the 
synchronous or asynchronous delivery of the shocking 
pulses. 

[0065] The ICTD 102 may further be designed with 
the ability to support high-frequency wireless communi- 
cation, typically in the radio frequency (RF) range. As 
illustrated in Fig. 2, the can 600 may be configured with 
a secondary, isolated casing 690 that contains circuitry 
for handling high-frequency signals. Within this sepa- 
rate case 690 are a high-frequency transceiver 692 and 
a diplexer 694. Highfrequency signals received by a 
dedicated antenna, or via leads 108, are passed to the 
transceiver 692. Due to the separate casing region 690, 
the transceiver handles the high-frequency signals in 
isolation apart from the cardiac therapy circuitry. In this 
manner, the high-frequency signals can be safely han- 
dled, thereby improving telemetry communication, with- 



out adversely disrupting operation of the other device 
circuitry. 

Exemplary Computing Device 

5 

[0066] Fig. 7 shows an exemplary computing device 
700 employed in the computing systems of the cardiac 
therapy network architecture 1 00. It includes a process- 
ing unit 702 and memory 704. Memory 704 includes 

10 both volatile memory 706 (e.g., RAM) and non-volatile 
memory 708 (e.g., ROM, EEPROM, Flash, disk, optical 
discs, persistent storage, etc.). An operating system and 
various application programs 710 are stored in non-vol- 
atile memory 708. When a program is running, various 

15 instructions are loaded into volatile memory 706 and ex- 
ecuted by processing unit 702. Examples of possible ap- 
plications that may be stored and executed on the com- 
puting device include the knowledge worker specific ap- 
plications 206 shown in Fig. 2. 

20 [0067] The computing device 700 may further be 
equipped with a network I/O connection 720 to facilitate 
communication with a network. The network I/O 720 
may be a wire-based connection (e.g., network card, 
modem, etc.) or a wireless connection (e.g., RF trans- 

25 ceiver, Bluetooth device, etc.). The computing device 
700 may also include a user input device 722 (e.g., key- 
board, mouse, stylus, touch pad, touch screen, voice 
recognition system, etc.) and an output device 724 (e. 
g., monitor, LCD, speaker, printer, etc.). 

30 [0068] Various aspects of the methods and systems 
described throughoutthis disclosure may be implement- 
ed in computer software or firmware as computer-exe- 
cutable instructions. When executed, these instructions 
direct the computing device (alone, or in concert with 

35 other computing devices of the system) to perform var- 
ious functions and tasks that enable the cardiac therapy 
network architecture 100. 

Presentation Architecture 

40 

[0069] One feature of the network architecture is a 
presentation architecture that enables presentation of 
data obtained from the implantable cardiac therapy de- 
vice to various knowledge workers. The presentation ar- 

45 chitecture places the data in a suitable format and pro- 
tocol to accommodate different types of computing de- 
vices with different Ul capabilities. The presentation ar- 
chitecture separates the processing and presentation 
functions so that decisions regarding how to present the 

so content are made independently of the collection and 
processing of the data. 

[0070] Fig. 8 shows the presentation architecture 800 
that is implemented by the network architecture. The 
presentation architecture 800 has three layers: an infor- 
55 mation source layer 802, a processing layer 804, and a 
presentation layer 806. The information source layer 
802 provides the data or information that is to be proc- 
essed and presented to the knowledge worker. This lay- 
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er includes data output by the ICTD, such as heart ac- 
tivity (e.g., IEGM), patient information, device operation 
data, analysis results from on-device diagnostics, and 
so on. It may further include other information made 
available for purposes of processing or better under- 
standing the ICTD data. 

[0071] The processing layer 804 performs the data 
handling and analytical processes. This layer contains 
the applications and methods that conform the data into 
content that will ultimately be presented to the knowl- 
edge workers. The processing layer 804 may include, 
for example, the processing system 204 and applica- 
tions 206 that create the content desired by the knowl- 
edge workers. 

[0072] The presentation layer 806 is responsible for 
getting the content to the knowledge worker in a form 
they prefer. This layer 806 contains the applications and 
processes that determine which content to present to 
whom, the format of the content, and the protocol by 
which to send the content. 

[0073] Fig. 9 shows one exemplary implementation of 
the presentation layer 806 configured as the distribution/ 
presentation system 208. The presentation layer 806 
enables effective delivery and presentation of content 
to many different types of computing devices, as repre- 
sented by exemplary devices 900(1 )-(8). It is anticipated 
that knowledge workers will utilize many diverse types 
of computing devices, including pagers 900(1), personal 
digital assistants (PDAs) 900(2), Web-enabled or 
"smart" phones 900(3), portable computers 900(4), fac- 
simile machines 900(5), cellular phones 900(6), data- 
bases 900(7), and desktop computers 900(8). These 
devices may be implemented using open standard soft- 
ware and protocols, or proprietary software and proto- 
cols. 

[0074] The presentation layer 806 includes a content 
component store 902 to store snippets of content ready 
to be presented to the knowledge worker. The content 
may include raw data, processed data, additional infor- 
mation added during processing, and so on. Although 
the content store 902 is illustrated in Fig. 9 as residing 
at the distribution/presentation system 208, it may also 
reside in the repository 202. 

[0075] The presentation layer 806 may further include 
a content selector 904 to choose the content compo- 
nents from store 902 for presentation to the various 
knowledge workers. For instance, the content selector 
904 may select patient-related data (e.g., IEGM, therapy 
parameters, patient information, etc.) for presentation to 
healthcare workers. It might further choose device-re- 
lated information (e.g., raw IEGM data) for presentation 
to the manufacturer. 

[0076] The content selector 904 maintains a set of 
knowledge worker records 906 in a database or other 
storage unit. The knowledge worker records 906 specify 
the worker's contact information, information preferenc- 
es, and computing resources. The records 906 track, for 
example, the worker's email address, phone numbers, 



and pager numbers. The records 906 might further 
specify the type of information desired by the knowledge 
worker and the type(s) of computing devices 900 that 
the knowledge worker uses. As one example, a record 

5 906 for a cardiac physician may specify the contact in- 
formation, the doctor's preference to see I EG M data out- 
put by the ICTD, and that the primary computing device 
is a Palm Pilot® PDA 900(2) with wireless communica- 
tion capabilities but limited Ul features. 

10 [0077] A user interface (Ul) specification store 910 
maintains the rules that dictate how the content is to be 
presented on different computing devices and software 
platforms. The computing devices 900(1 )-(7) have a 
wide variety of Ul features and capabilities, ranging from 

*5 high-resolution color monitors, to single-line LCD dis- 
plays or audio alarms, to database structures and fac- 
simile machines. 

[0078] The Ul specification store 910 maintains one 
or more Ul definitions 912 that specify device require- 

20 ments for visual/audio output. The Ul definitions 91 2 in- 
clude such parameters of whether devices have a dis- 
play and if so, the display type (e.g., LCD, CRT, LED, 
etc.), display size, whether the display is capable of 
showing graphics and/or color, whether audio is possi- 

25 ble, and so on. These Ul definitions 91 2 help the content 
selector 904 identify which snippets of information in the 
content store 902 should be selected for a given device 
specified in the knowledge worker record 906. 
[0079] The Ul specification store 910 also includes 

30 one or more style sheets 91 4 that specify how the con- 
tent is to be arranged for a given computing device. The 
style sheets 914 specify the format of the information, 
such as HTML, XML, SNMP (Simple Network Manage- 
ment Protocol), etc. The sheets also dictate the type of 

35 content that can be included, such as graphical compo- 
nents, text, audio, video, and so on. 
[0080] The presentation layer 806 might also include 
a content formatter 920 to place the content into the ap- 
propriate format specified by the Ul specification store 

40 91 0 for a target computing device. For instance, if a par- 
ticular knowledge worker utilizes a laptop computer that 
is capable of receiving HTML documents, the content 
formatter 920 formats the content in HTML for effective 
presentation. If another knowledge worker has a cellular 

45 phone, the content formatter 920 may format the content 
text that can be readily depicted on a limited display. 
[0081] A delivery protocol encoder 922 encodes the 
formatted content according to the protocols supported 
by the computing devices and networks used by the 

so knowledge worker. There are many possible protocols, 
including HTTP, TCP/IP, WAP, Bluetooth, etc. Depend- 
ing upon the preferences specified in the knowledge 
worker records 906, the delivery protocol encoder 922 
encodes the content to the appropriate delivery protocol 

55 for subsequent distribution to the devices operated by 
the knowledge workers. 

[0082] Separating the presentation and processing 
layers and implementing Ul definitions and style sheets 



9 



17 



EP1 310 272 A2 



18 



enables the architecture to distribute content produced 
by multiple applications to a wide assortment of com- 
puting devices without requiring unique Uls for each 
computing device. Suppose there are three applications 
that produce content to be distributed to four different 5 
computing devices of the knowledge workers. If the 
presentation layer were integrated with the processing 
layer, the application developer would need to write a 
specific Ul for each device, resulting in twelve different 
versions of Ul code (i.e., the number of applications 
times the number of devices). 

[0083] By separating the presentation layer, however, 
independent Ul definitions 912(1 )-(3) can be developed 
to specify Ul requirements imposed by individual appli- 
cations. Style sheets 910(1)-(4) can be created to de- 
scribe what features individual devices are able to sup- 
port. Combining the Ul definition with a style sheet dic- 
tates what content is presented and how it is presented 
for a given computing device. In this example, the archi- 
tecture allows, at most, the creation of seven definitions/ 
sheets to facilitate presentation of content from three ap- 
plications on four devices (i.e., the number of applica- 
tions plus the number of devices), down from twelve 
separate versions. 

[0084] This architecture is easily adopted to support 
new computing devices. A developer defines a new Ul 
definition and/or a style sheet to enable presentation of 
content on the new device. This saves time and money 
in that developers are not forced to modify applications 
as Ul capabilities of the end-user computing devices 
change. 

Presentation Operation 

[0085] Fig. 10 shows a process 1000 for presenting 
content to the knowledge workers. Aspects of this proc- 
ess may be implemented in hardware, firmware, or soft- 
ware, or a combination thereof. 
[0086] At block 1002, the distribution/presentation 
system 208 determines what computing resources are 
available for the knowledge worker who is intended to 
receive the information. The system consults the knowl- 
edge worker records 906 to identify the types of com- 
puting devices specified by the knowledge worker. At 
block 1004, the system ascertains the features and ca- 
pabilities of the computing resources of the intended 
knowledge worker. Such features may include display 
type, display size, graphical capabilities, color capabili- 
ties, etc. 

[0087] At block 1006, the content selector 904 selects 
the content to be delivered to the knowledge worker 
based, in part, on the capabilities of the computing re- 
sources. For instance, if the knowledge worker is carry- 
ing a PDA or phone of limited screen size, the content 
selector 904 extracts summary statements or phrases 
from the content component store 902 that can be pre- 
sented on the device. For instance, the content selector 
might choose a statement "IEGM for Patient X is ready 



for viewing". Such a message would inform the knowl- 
edge worker that pertinent patient data is ready for 
downloading next time the knowledge worker is at a de- 
vice capable of viewing and analyzing IEGM charts. For 
devices of higher capabilities (e.g., portable or desktop 
computer), the content selector may choose full data 
graphs and/or commentary to present to the knowledge 
worker. 

[0088] At block 1008, the content formatter 920 for- 
mats the selected content into suitable formats for pres- 
entation on the knowledge worker's computing device. 
Possible formats include HTML, XML, and SNMP. At 
block 101 0, the delivery protocol encoder 922 encodes 
the content according to a protocol supported by the tar- 
get network and computing device. Examples of possi- 
ble protocols include HTTP, TCP/IP, WAP, Bluetooth, 
etc. At block 1 01 2, the system 208 delivers the content 
to the knowledge worker's computing device, where it 
is presented for review and analysis by the knowledge 
worker. 
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25 1 . A system comprising an implantable cardiac thera- 
py device (1 02) and a computing network (1 20) con- 
figures to communicate with an receive data output 
by the implantable cardiac therapy device (1 02) and 
to distribute the data to computing devices 
30 (140,144,148,152) associated with knowledge 
workers (130,132,134,136) who are interested in 
the data, characterised by a presentation architec- 
ture (800) implemented by the computing network 
(1 20) to distribute the data to the computing devices 
35 (140,144,148,152) according to different formats 
and protocols supported by the computing devices. 

2. A system as claimed in Claim 1 , characterised in 
that the presentation architecture (800) comprises 

40 a processing layer (804) to process the data re- 
ceived from the implantable cardiac therapy device 
(102) and a presentation layer (806) separate from 
the processing layer (804), to format and encode 
the data according to the formats and protocols sup- 
45 ported by the computing devices. 

3. A system as claimed in Claim 1 or Claim 2, charac- 
terised in that the presentation architecture (800) 
comprises one or more records that specify the 

so computing devices used by the knowledge workers, 
and a specification store (910) to maintain user in- 
terface definitions (912) and style sheets (914) 
specifying how the data should be presented on a 
particular computing device. 

55 

4. A system as claimed in any preceding Claim, char- 
acterised in that the presentation architecture 
(800) comprises a content formatter (920) to format 
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the data in different formats for presentation on the 
computing devices, and a protocol encoder (922) to 
encode the data according to different protocols 
supported by the computing devices. 

5 

5. A system as claimed in any preceding Claim, char- 
acterised in that the implantable cardiac therapy 
device (102) comprises a cardiac stimulation de- 
vice. 

10 

6. A system as claimed in any preceding Claim, char- 
acterised in that the computing network (120) is 
configured to distribute the data to computing de- 
vices (140,144,148,1 52) selected from a computer, 

a portable computer, a personal digital assistant, a '5 
wireless phone, a facsimile, and a database. 

7. A presentation architecture (800) for presenting da- 
ta output by an implantable cardiac therapy device 
(102) to various computer devices 20 
(140,144,148,152) operated by knowledge workers 
(130,132,134,136) who are interested in the data, 
characterised In that the presentation architecture 
(800) comprises: an information source layer (802) 

to collect the data from the implantable cardiac ther- 25 
apy device (1 02); a processing layer (804) to proc- 
ess the data collected by the information source lay- 
er (802), and a presentation layer (806), separate 
from the processing layer (804), to format and en- 
code the data according to the different formats and so 
protocols supported by the computing devices. 

8. A presentation architecture as claimed in Claim 7, 
characterised in that the presentation layer (806) 
comprises one or more records that specify the 35 
computing devices operated by the knowledge 
workers, and a specification store (91 0) to maintain 
user interface definitions (912) and style sheets 
(914) specifying how the data should be presented 

on a particular computer device. 40 

9. A presentation architecture as claimed in Claim 7 
or Claim 8, characterised in that the presentation 
layer (806) comprises a content formatter (92)) to 
format the data for presentation on the computing 45 
devices, and a protocol encoder (922) to encode the 
data according to different protocols supported by 

the computing devices. 

10. A presentation system (800) for presenting data in so 
a network system for gathering data from an im- 
plantable cardiac therapy device (102) and 
processing the data for distribution to various 
knowledge workers, characterised in that the 
presentation system (800) comprises: one or more 55 
records that specify computing devices used by the 
knowledge workers (1 40,1 44, 1 48,1 52), a specifica- 
tion store (91 0) to maintain user interface definitions 



(912) and style sheets (914) specifying how the da- 
ta should be presented on the computing devices; 
a content formatter (920) to format the data in dif- 
ferent formats for presentation on the computing 
devices; and a protocol encoder (922) to encode the 
data according to different protocols supported by 
the computing devices. 

11. A presentation system as claimed in Claim 10, 
characterised by a content selector (904) to 
choose which portions of the data to format and en- 
code for presentation on the computing devices, the 
content selector (904) making the choice according 
to capabilities of the computing devices. 

12. A presentation system (800) for presenting data in 
a network system for gathering data from an im- 
plantable cardiac therapy device (102) and 
processing the data for distribution to various 
knowledge workers, characterised in that the 
presentation system (800) comprises: ascertaining 
means for ascertaining capabilities of computing re- 
sources (140,144,148,152) available to the knowl- 
edge workers (130,132,134,136), wherein different 
knowledge workers utilise different types of comput- 
ing device with different capabilities; formatting 
means (920) for formatting the data from the im- 
plantable cardiac therapy device (1 02) according to 
the capabilities of the computing resources; and en- 
coding means (922) for encoding the data from the 
implantable cardiac therapy device (1 02) according 
to different protocols supported by the computing 
resources. 

13. A presentation system as claimed in Claim 12, 
characterised by content selector means (904) for 
selecting which portions of the data to format and 
encode for presentation on the computing devices 
(140,144,148,152) based on the capabilities of the 
computing devices. 

14. A presentation system as claimed in Claim 12 or 
Claim 13, characterised by specification means 
(91 0) for specifying user interface and layout criteria 
for the computing resources. 

15. A presentation system as claimed in any of Claims 
12 to 14, characterised by distribution means for 
distributing the data to the computing devices. 

16. A method of processing data in a network system 
for gathering data from an implantable cardiac ther- 
apy device (1 02) and processing the data for distri- 
bution to various knowledge workers 
(130,132,134,136), characterised In that the 
method comprises: ascertaining capabilities of 
computing resources (140,144,148,152) available 
to the knowledge workers, wherein different knowl- 
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edge workers utilise different types of computing 
device with different capabilities; formatting the da- 
ta from the implantable cardiac therapy device 
(1 02) according to the capabilities of the computing 
resources; and encoding the data from the implant- 5 
able cardiac therapy device according to protocols 
supported by the computing resources. 

17. A method as claimed in Claim 16, characterised 

by choosing different portions of data to format and 10 
encode based on the capabilities of the computing 
devices. 

1 8. A method as claimed in Claim 1 6 or Claim 1 7, char- 
acterised by maintaining user interface and layout '5 
criteria for the computing resources. 

19. A method as claimed in any of Claims 16 to 18, 
characterised by distributing the data to the com- 
puting devices. 20 
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